Added eep draft for nominal types #60
Conversation
|
I am missing a more formal definition for the suggested nominal types. Such as: A function that has a
A function that has a
A function that has a
A function that has a
"supertype" and "subtype" also needs to be defined, and maybe "compatible structural type" |
|
That's what I though opaque types are. My interpretation of opaque types is that you can't assume anything about what they are so you need to treat them as nominal types. Type checkers probably differ here though. I don't know what Dialyzer does. |
|
@RaimoNiskanen It seems that my intentional avoidance of subtyping in the EEP draft causes more problems than benefits. I used 'nested nominals' instead of 'subtyping', because I wanted to emphasize that the supertypes and subtypes accepted are nominal supertypes and nominal subtypes. In Erlang, the only way to declare a nominal subtype is to declare a nested nominal of the form I'd phrase it as follows (same for A function that has a -spec that states an argument to be nominal type
|
|
@lucioleKi, and what gives for return types? |
|
@zuiderkwast Yes, opaque types have always been type-checked by names in Dialyzer, just with more restrictions. Dialyzer assumes no knowledge about opaque's structure, does not consider subtyping, etc. That's why the proposed nominal type-checking can cover opaque type-checking internally in Dialyzer. Nominal types are 'transparent' though. This EEP suggests a way to support nominal types and type-checking without opacity. |
|
@RaimoNiskanen The examples A function that has a -spec that it returns a nominal type b/0 may return the following without Dialyzer raising an error:
|
|
Great! I think these definitions should be in the EEP. |
eeps/eep-XXX.md
Outdated
| - 4711 and 42 are not structurally compatible. | ||
| - 4711 and `integer()` are structurally compatible. (Their intersection | ||
| is the value 4711.) | ||
| - `list(any_type)` and `[]` are structurally compatible. |
There was a problem hiding this comment.
Since you write the reason, may it helps the reader if you write their intersection as in the prev. point above
|
A general comment; I think the EEP should at least try to be less Dialyzer-centric. When the text can be more generic, talk about "the type checker" and how nominals are supposed to be handled by "the type checker"; any type checker. When talking about the implementation the text must of course talk about Dialyzer... |
This commit adds the eep draft for nominal types. I plan to make a post on Erlang forum, introducing nominal types. The post will refer to this pull request.